src/main/java/com/example/solidconnection/chat/dto/UnreadCountDto.java (1)

3-8: DTO 투영 안정성·가독성 개선 제안(Long 래핑, 네이밍 명확화).

• 1. 호환성. JPQL COUNT는 Long을 반환하므로, 레코드 생성자 파라미터를 primitive long 대신 Long으로 두면 프로바이더별 박싱/언박싱 이슈를 예방할 수 있습니다.
• 2. 가독성. 필드명을 count → unreadCount로 바꾸면 도메인 의미가 즉시 드러납니다.
• 3. 변경 영향. 조회 전용 DTO라 사이드 이펙트는 없고, 호출부 리네임만 필요합니다.

아래 diff 적용 후, 컴파일 에러가 없는지와 JPQL 생성자 표현식이 정상 바인딩되는지 확인 부탁드립니다.

-public record UnreadCountDto(
-        long chatRoomId,
-        long count
-) {
+public record UnreadCountDto(
+        Long chatRoomId,
+        Long unreadCount
+) {

src/main/java/com/example/solidconnection/siteuser/repository/SiteUserRepository.java (1)

23-23: 대량 조회 파라미터를 Collection으로 일반화하고 빈 리스트 처리 컨벤션 합의.

• 1. 유연성. List → Collection으로 넓히면 Set 등 다양한 컨테이너를 바로 받을 수 있어 중복 제거·메모리 효율에 유리합니다.
• 2. 안정성. 파라미터가 비었을 때 서비스 레이어에서 즉시 빈 결과를 반환하는 가드(early-return) 컨벤션을 두면 불필요한 DB round-trip을 피할 수 있습니다.
• 3. 성능. IN 절 파라미터가 매우 클 수 있으니(수천 개 이상) 호출부에서 적절한 청크 분할도 고려해 주세요.

아래 시그니처 변경 후, 호출부 타입 불일치가 없는지 점검해 주세요.

-    List<SiteUser> findAllByIdIn(List<Long> ids);
+    List<SiteUser> findAllByIdIn(java.util.Collection<Long> ids);

추가 import가 필요하다면 다음 한 줄을 상단 import 블록에 포함하세요.

import java.util.Collection;

src/main/java/com/example/solidconnection/chat/repository/ChatMessageRepository.java (2)

33-50: 인덱스 제안으로 배치 쿼리 체감 성능 확보.

• 1. ChatMessage(chat_room_id, created_at) 복합 인덱스: 최신 메시지 선정·미읽음 비교 모두 가속.
• 2. ChatReadStatus(chat_room_id, chat_participant_id): 조인 키 정합성·룩업 최적화.
• 3. ChatParticipant(chat_room_id, site_user_id): 사용자-채팅방 역방향 탐색 최적화.

원하시면 DDL 스니펫을 엔티티 @Index 또는 마이그레이션 스크립트 형태로 드래프트해 드리겠습니다.

---

33-50: 미읽음 배치 카운트 쿼리 성능·가독성 개선 제안

1. 조인 경로 재구성
     - cm.chatRoom.chatParticipants를 JOIN하여 correlated 서브쿼리(SELECT cp.id …) 제거
2. COUNT DISTINCT 적용
     - COUNT(cm) 대신 COUNT(DISTINCT cm.id) 사용으로 조인 폭발 시 중복 방지
3. 가독성 강화
     - 연관 엔티티 경로 조인으로 의도를 명확히 표현 (JOIN cm.chatRoom.chatParticipants cp)
4. 빈 chatRoomIds 처리
     - chatRoomIds가 빈 경우, 호출부에서 즉시 빈 결과를 반환하는 가드 추가 권장

실제 엔티티 필드명(chatParticipants, chatRoomId, chatParticipantId 등)이 다를 수 있으니 매핑을 확인하고 적절히 치환해 주세요.

-    @Query("""
-           SELECT new com.example.solidconnection.chat.dto.UnreadCountDto(
-               cm.chatRoom.id,
-               COUNT(cm)
-           )
-           FROM ChatMessage cm
-           LEFT JOIN ChatReadStatus crs ON crs.chatRoomId = cm.chatRoom.id
-               AND crs.chatParticipantId = (
-                   SELECT cp.id FROM ChatParticipant cp
-                   WHERE cp.chatRoom.id = cm.chatRoom.id
-                   AND cp.siteUserId = :userId
-               )
-           WHERE cm.chatRoom.id IN :chatRoomIds
-           AND cm.senderId != :userId
-           AND (crs.updatedAt IS NULL OR cm.createdAt > crs.updatedAt)
-           GROUP BY cm.chatRoom.id
-           """)
+    @Query("""
+           SELECT new com.example.solidconnection.chat.dto.UnreadCountDto(
+               cm.chatRoom.id,
+               COUNT(DISTINCT cm.id)
+           )
+           FROM ChatMessage cm
+           JOIN cm.chatRoom.chatParticipants cp
+           LEFT JOIN ChatReadStatus crs
+             ON crs.chatRoomId = cm.chatRoom.id
+            AND crs.chatParticipantId = cp.id
+           WHERE cp.siteUserId = :userId
+             AND cm.chatRoom.id IN :chatRoomIds
+             AND cm.senderId <> :userId
+             AND (crs.updatedAt IS NULL OR cm.createdAt > crs.updatedAt)
+           GROUP BY cm.chatRoom.id
+           """)

src/main/java/com/example/solidconnection/chat/dto/ChatRoomData.java (1)

9-24: toMap 중복 키 예외 방지와 불변 Map 래핑으로 안전성·예측가능성 향상.

• 1. 중복 키 안전. 실무에서 중복이 거의 없더라도 toMap 기본 동작은 중복 시 IllegalStateException을 던집니다. 머지 전략을 명시해 방어적으로 갑시다.
• 2. 결정 규칙. latestMessages는 createdAt(동률 시 id) 기준 최댓값을 선택, unreadCounts는 동일 키 중복 시 최댓값 유지, partnerUsers는 최초 항목 유지가 합리적입니다.
• 3. 불변성. Map.copyOf로 결과를 불변화하면 이후 파이프라인에서 실수로 변형되는 것을 막습니다.
• 4. 제너럴리티. 파라미터 타입을 List → Collection으로 넓히면 입력 유연성이 올라갑니다.

아래 diff는 충돌 방지를 위해 핵심 라인만 제시합니다.

-    public static ChatRoomData from(List<ChatMessage> latestMessages,
-                                    List<UnreadCountDto> unreadCounts,
-                                    List<SiteUser> partnerUsers) {
+    public static ChatRoomData from(
+            java.util.Collection<ChatMessage> latestMessages,
+            java.util.Collection<UnreadCountDto> unreadCounts,
+            java.util.Collection<SiteUser> partnerUsers) {
         return new ChatRoomData(
-                latestMessages.stream().collect(Collectors.toMap(msg -> msg.getChatRoom().getId(), msg -> msg)),
-                unreadCounts.stream().collect(Collectors.toMap(UnreadCountDto::chatRoomId, UnreadCountDto::count)),
-                partnerUsers.stream().collect(Collectors.toMap(SiteUser::getId, user -> user))
+                java.util.Map.copyOf(
+                    latestMessages.stream().collect(Collectors.toMap(
+                        msg -> msg.getChatRoom().getId(),
+                        msg -> msg,
+                        (a, b) -> {
+                            var aTs = a.getCreatedAt();
+                            var bTs = b.getCreatedAt();
+                            if (aTs.equals(bTs)) {
+                                return a.getId() >= b.getId() ? a : b; // 동률 시 더 큰 id
+                            }
+                            return aTs.isAfter(bTs) ? a : b;         // 최신 시각 우선
+                        }
+                    ))
+                ),
+                java.util.Map.copyOf(
+                    unreadCounts.stream().collect(Collectors.toMap(
+                        UnreadCountDto::chatRoomId,
+                        UnreadCountDto::unreadCount,
+                        java.lang.Long::max
+                    ))
+                ),
+                java.util.Map.copyOf(
+                    partnerUsers.stream().collect(Collectors.toMap(
+                        SiteUser::getId,
+                        java.util.function.Function.identity(),
+                        (a, b) -> a
+                    ))
+                )
         );
     }

src/main/java/com/example/solidconnection/chat/service/ChatService.java (4)

71-76: 목록 정렬 기준을 ‘최근 메시지’로 고정할지 확인하고, 필요 시 서비스에서 정렬을 적용해 주세요.
현재는 리포지토리 반환 순서를 그대로 사용합니다. 제품 기대가 “최근 대화순”이라면 최신 메시지 시각 기준 내림차순 정렬을 서비스에서 보장하는 편이 안전합니다.
1) 리포지토리 레벨에서 이미 정렬을 보장한다면 유지해도 됩니다.
2) 정렬 보장이 명확하지 않다면 아래 정렬을 권장합니다. null 최신 메시지는 뒤로 밀리고, 최신순으로 정렬됩니다.

정렬 추가 예시(최소 변경).

-        List<ChatRoomResponse> responses = chatRooms.stream()
-                .map(chatRoom -> createChatRoomResponse(chatRoom, siteUserId, chatRoomData))
-                .toList();
+        List<ChatRoomResponse> responses = chatRooms.stream()
+                .sorted(java.util.Comparator.comparing(
+                        (ChatRoom room) -> {
+                            ChatMessage lm = chatRoomData.latestMessages().get(room.getId());
+                            return lm != null ? lm.getCreatedAt() : null;
+                        },
+                        java.util.Comparator.nullsLast(java.util.Comparator.naturalOrder())
+                ).reversed())
+                .map(chatRoom -> createChatRoomResponse(chatRoom, siteUserId, chatRoomData))
+                .toList();

참고: 위 코드는 java.util.Comparator 정규 참조를 사용해 별도 import 없이 동작합니다.

---

61-76: 행위 변화 회귀 테스트를 보강해 주세요.
배치 로딩으로 전환되며 정렬, 중복 제거, 비어있는 최신 메시지 케이스 등 경계조건을 검증하는 테스트가 중요합니다.
1) 채팅방 2개 이상에서 최신 메시지 시각 기준 정렬이 기대대로인지 검증해 주세요.
2) fetch-join으로 인한 중복 결과가 응답에 나타나지 않는지 검증해 주세요.
3) 최신 메시지가 존재하지 않는 방에 대한 폴백(content="", createdAt=null) 계약을 검증해 주세요.
4) 미읽음 카운트가 없는 방의 기본값이 0으로 세팅되는지 검증해 주세요.
5) 파트너 사용자가 비정상/삭제 상태일 때의 처리 정책을 검증해 주세요.

---

78-89: 파트너 사용자 배치 조회에서 중복 ID를 제거해 IN 절을 최적화해 주세요.
같은 상대와 여러 방이 없더라도, 스트림 연산상 중복 ID가 섞일 가능성은 존재합니다. 불필요한 IN 항목을 제거하면 DB 파서 부담을 줄일 수 있습니다.
또한, 본 블록에서 findPartner가 예외를 던지면 전체 목록 구성이 중단됩니다. 리포지토리 단계가 1:1 방만 보장하는지 함께 확인해 주세요.
1) ID 중복 제거를 권장합니다.
2) 그룹방/비정상 데이터가 섞일 경우 전체 실패가 발생하므로, 리포지토리에서 철저히 1:1 방만 반환되도록 보장하거나, 서비스에서 예외 전파 정책을 명확히 해 주세요.
3) 성능과 가독성을 위해 findPartner 결과를 미리 roomId->partnerUserId 맵으로 캐싱해 두고 재사용하는 구조도 고려할 수 있습니다.

중복 제거 최소 변경 예시.

-        List<Long> partnerUserIds = chatRooms.stream()
-                .map(chatRoom -> findPartner(chatRoom, siteUserId).getSiteUserId())
-                .toList();
+        List<Long> partnerUserIds = chatRooms.stream()
+                .map(chatRoom -> findPartner(chatRoom, siteUserId).getSiteUserId())
+                .distinct()
+                .toList();

---

91-107: 파트너 사용자 누락 시 전체 실패 처리 정책을 재확인해 주세요.
현재는 partnerUser가 null이면 USER_NOT_FOUND 예외를 던져 전체 리스트 구성을 중단합니다. 운영 관점에서 “문제 방만 건너뛰고 나머지를 계속 보여준다”가 더 유리할 수도 있습니다.
1) 사용자 탈퇴/비공개 전환 등으로 파트너 정보가 일시적으로 비어도 목록 전체를 차단할지 정책을 확인해 주세요.
2) 최신 메시지가 없는 방에서 content=""와 createdAt=null 폴백이 계약과 일치하는지 확인해 주세요. 직렬화/클라이언트 파싱이 null을 허용하는지 검토해 주세요.
3) findPartner가 본 메서드와 getChatRoomData 양쪽에서 두 번 호출됩니다. 1:1 방에서 비용은 작지만, 중복 계산을 줄이기 위해 roomId->partnerUserId 맵을 미리 만들어 전달하는 구조를 고려할 수 있습니다.

참고: 예외 대신 건너뛰기 방식을 택한다면, map 이전에 filter 단계에서 파트너 유효성 검사를 선행하는 패턴이 유용합니다.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.